Read It Again - Team Topologies

Wir haben im Blog schon öfter Literatur zu verschiedenen Themen betrachtet, wie zum Beispiel Legacy Code oder Dysfunktionen in Teams. Team Topologies geht auf die Ebene des Organisationsdesigns und der Team-Interaktion ein, denn auch diese ist für effektive Software-Teams notwendig.

Man könnte jetzt denken, das ist hauptsächlich ein Thema für Manager und Organisationsentwickler, aber die zugrunde liegenden Prinzipien gelten für alle Team-Mitglieder in Softwareentwicklungs-Teams und sind daher auch für sie interessant.

Team Topologies ist 2019 erschienen und trifft ein Kernproblem in der heutigen Softwareentwicklung: Wie können wir, auch in größerem Umfang, dauerhaft zügig und in hoher Qualität unsere Software weiterentwickeln?

Bekannt geworden ist Team Topologies aber vor allem durch die 4 Team-Typen und 3 Team-Interaktionen, die die Autoren Matthew Skelton und Manuel Pais in Software-Firmen identifiziert haben.

An Conway’s Law führt kein Weg vorbei

Conway’s Law ist einer der Grundpfeiler, auf denen das Buch fußt. Mel Conway hat bereits 1968 formuliert, dass Organisationen, die Systeme entwerfen, dabei gezwungenermaßen die Kommunikationsstrukturen abbilden. Daraus folgt, dass Team-Interaktionen und Software-Architektur nur gemeinsam betrachtet werden können.

Bekanntermaßen müssen Teams, um nachhaltig und schnell neue Features entwickeln zu können (Team Topologies nutzt hier das Wording „rapid flow of changes“), crossfunktional und an separaten Services ausgerichtet sein.

Es ist aber auch wichtig, dass bei der Kommunikation zwischen Teams auch darauf geachtet wird, dass dieser sinnvoll Grenzen gesetzt werden: Wenn jeder mit jedem kommuniziert, kommt am Schluss ein monolithisches, verwobenes System heraus, dass schnelle Änderungen erschwert - auch das ist eine Folge aus Conway’s Law!

Jedes Team hat ein gewisses Maß an kognitiver Last, mit der es umgehen kann

Ein zweiter essentieller Punkt ist der Bezug des Buches auf die kognitive Last in den Teams. Jedes Team kann nur mit einem bestimmten Maß kognitiver Last umgehen und die Teams müssen daher so geschnitten sein, dass dieses Maß nicht überschritten wird.

Team Topologies liefert hierzu Heuristiken, die helfen können zu ermitteln, ob ein Team zu viel kognitive Last hat: Dabei werden Domänen nach Komplexität (einfach/kompliziert/komplex) unterteilt. Teams können 2-3 einfache Domänen verantworten, sollten aber nicht mehrere Domänen hoher Komplexität in ihrer Zuständigkeit haben und bei einer komplexen Domäne überhaupt keine weiteren Domänen betreuen.

Vier Team-Topologien und drei Arten von Team-Interaktionen

Ein Hauptbeitrag des Buches ist zweifelsohne die Identifikation der vier Team-Topologien und drei Arten von Team-Interaktionen.

Die vier Team-Topologien definieren verschiedene Typen von Teams, mittels derer eine saubere Team-Struktur in Softwareentwicklungs-Unternehmen erreicht werden kann:

Stream-aligned Teams bearbeiten selbstständig einen Strom an Themen in einer bestimmten Domäne und liefern innerhalb dieser so einen Mehrwert
Enabling Teams bestehen aus Spezialisten für ein bestimmten Thema und helfen, dieses Wissen in die Teams zu tragen oder dort einzubringen
Complicated-subsystem Teams verantworten ein Subsystem, dass eine hohe Komplexität besitzt und entkoppelt von den stream-aligned Teams betreut und dort eingesetzt werden kann
Platform Teams stellen Infrastruktur quasi als „internes Produkt“ für stream-aligned Teams bereit, dass diese nutzen können, um selbstständig, d.h. ohne große Team-übergreifenden Aufwände, fachliche Stories umzusetzen.

Je nach Team-Typ werden dabei folgende Arten der Interaktion zwischen den Teams genutzt:

Collaboration: Ein Team arbeitet eng mit einem anderen Team zusammen
X-as-a-service: Ein Team nutzt den Dienst eines anderen Teams mit möglichst wenig Kollaboration
Facilitation: Ein Team hilft einem anderen Team, Hindernisse zu überwinden

Diese Arten unterscheiden sich in der Eignung für die verschiedenen Team-Typen. Während stream-aligned Teams, wenn auch meist nur temporär, oft im Kollaborationsmodus mit anderen Teams zusammenarbeiten, streben Platform Teams eine X-as-a-service-Interaktion an. Auch kann sich die Art der Interaktion über die Zeit hinweg ändern. Wichtig aber ist, dass mithilfe dieser Klassifizierung die Art der Interaktion explizit gemacht werden kann. So lassen sich Mehrdeutigkeit und damit verbundene Mehraufwände vermeiden.

Und sonst?

Während die Team-Topologien und Interaktionen sicherlich die bekanntesten Themen des Buches darstellen, enthält es noch einige weitere Perlen, mit denen man sich ebenfalls im Detail beschäftigen sollte. Wir wollen hier kurz noch auf zwei solcher Punkte eingehen:

Zum Einen beschreiben die Autoren explizit verschiedene Typen von Monolithen. Wenn es darum geht, diese zu vermeiden, denkt man oft an Software, die monolithisch strukturiert ist. Bei einem Monolithen kann es sich aber auch um das Build-System, ein allumfassendes Modell (Konsistenz um jeden Preis), oder auch um eine monolithische Denkweise handeln (wenn one-size-fits-all den Teams vorgegeben wird und sie so in ihrer Arbeit unnötigerweise eingeschränkt werden).

All dies hat zur Folge, dass die kognitive Last in den Teams wächst und sie so nicht mehr effektiv arbeiten können.

Ein weiteres wichtiges Thema behandelt das Buch mit den sogenannten Fracture Planes: Damit sind mögliche Arten von Grenzen gemeint, anhand derer sich Software modularisieren und so auf verschiedene Teams aufteilen lässt. Oft werden hier Business Domains für die Aufteilung verwendet. Je nach Art der Software und der Domäne können aber auch andere Kriterien sinnvoll sein, wie z.B. Compliance, Änderungshäufigkeit, Risikobetrachtung und noch einige mehr.

Fazit

Es gibt Bücher, bei denen hat man nach kurzer Zeit den Eindruck, die Kernidee ist vermittelt und jetzt wird das Thema nur noch wiederholt. Team Topologies ist überhaupt nicht so. Das Buch liefert von Anfang bis Ende wertvolle Impulse und kann so ruhigen Gewissens zum Standardrepertoire moderner Software-Literatur gezählt werden.